一套 QA 流程可以看起來很有條理，同時卻把大量依賴寄託在建立它的那個人身上。我可能知道要跑哪一個評估、為什麼存在那個特定門檻、哪一個結果值得調查，以及發生意外的時候該找誰。但如果我請了一個長假，或離開了這家公司，這些知識就可能從團隊的日常工作流程中消失。文件還在，可是下一位 QA 工程師可能要花上好幾天，重建那些從來沒被寫下來的決定。

這改變了我對「成功交接」的定義。交接品質不是用手冊的厚度來衡量的，而是看一位新手能否用它獨立完成一個完整的驗證循環，並且在出錯時辨認得出來。我希望接手的人理解的不只是我走過的步驟，還有步驟背後的理由。一本有用的手冊，應該讓工作變得可轉移，而不需要原作者的口頭補充。

1. 手冊需要的六個區塊

我會把 QA 手冊組織成六個彼此銜接的區塊：策略圖（strategy map）、黃金集與資料格式（schema）、評分標準（rubric）、關卡規格（gate specs）、回饋迴路，以及已知限制。前三個主要回答「我該怎麼執行驗證？」策略圖解釋哪些風險值得關注、為什麼某些區域得到比其他區域更深的測試。黃金集與資料格式指出有哪些案例、它們的必填欄位，以及維護方式。評分標準解釋結果如何被解讀，讓新手不必自行發明評分準則。合起來，這三個區塊給了下一位工程師一個起點、一組輸入，以及一套評估所見的方法。對像我這種透過前端與後端測試、沒有原始碼直接存取權的人來說，手冊也應該寫清楚：必要的測試帳號、環境資訊、評估紀錄與可用工具，分別可以在哪裡找到。

剩下三個區塊回答「我該如何決定下一步？」關卡規格說明哪些條件允許推進、哪些阻止推進，以及誰有權限核准例外。回饋迴路描述新發現的案例如何被審查並納入未來的驗證。已知限制則指出未解決的風險、尚未涵蓋的部分，以及不該被誤認為既成事實的假設。

手冊交接文件

上面的範例以一張交接表展示了這個結構，欄位涵蓋現況、未完成項目，以及下一位必須知道的事。其中的例子包括：缺了尖峰負載場景的策略圖、長尾涵蓋有限的黃金集，以及還在觀察模式中運作的成本關卡。這些細節之所以要緊，是因為它們區分了已完成的工作與尚未完成的決定。六個區塊中少掉任何一個，就會留下一個新手可能必須回去問前任的問題。

2. 可重現性檢查：讓新手獨立跑一次

評估一份交接最有說服力的方法，是讓一個對流程不熟悉的人，只靠文件完成一整個驗證循環。我會給新手一個定義好的任務，例如在指定的測試環境中評估一組準備好的助手回應，但我不會帶著他做。他應該要能找到輸入、辨認出相關設定、執行驗證、記錄結果，並把自己的發現與前一次執行相比較。如果結果不同，他應該能夠調查差異，並說明什麼證據支持自己的結論。目標不見得是重現一模一樣的 AI 措辭，而是依據同一套已寫成文件的規則，得到一個站得住腳的判斷。

我會把每一次的中斷都當成一份關於交接本身的發現。如果新手找不到正確的測試帳號，代表文件需要更清楚的索引；如果他不知道某個結果算不算可接受，代表決策指引不完整；如果缺少必要的權限，代表環境存取說明需要修正。任何需要我用嘴巴補一句的部分，都暴露了一個尚未被轉移出去的依賴。所以我不會把問題回答一次就翻頁，而是先更新手冊或存取程序，再請新手重做那一步。這讓交接演練變成一份對文件的實測，而不是一場「流程應該如何運作」的簡報。

3. 交接前的自我檢查：只活在一顆腦袋裡的知識

交接中最危險的缺口，往往不是缺檔案，而是沒被寫下來的慣例。團隊會說「大家都知道我們用那個門檻」，卻沒有人記得它是誰核准的、基於什麼理由。另一種慣例決定了評估案例什麼時候被加入、衝突的評分如何裁決，或排定的驗證失敗時該找誰。這些規則對跟它相處了幾個月的人來說顯而易見，對新手卻完全不可見。在交出流程之前，我會逐一挑戰每一個假設：這條規則記錄在哪裡？它的理由是什麼？誰可以修改它？如果它不再適用，該發生什麼？ 如果我無法從手冊回答這些問題，這份資訊就還沒準備好被轉移。

交接自我檢查：

⬜ 新手可以在沒有協助的情況下，完整跑一輪並做出報告。
⬜ 手冊中的每一條規則都回答了「為什麼」，而不只是「怎麼做」。
⬜ 所有路徑、權限與環境設定都可被驗證，而不是靠記憶。
⬜ 已知限制與未解風險都有列出，並附上重新檢視它們的條件。
⬜ 存在一份聯絡清單：失敗時找誰、誰可以豁免、誰負責新案例。

上面的範例提供了一份實用的五點自我檢查。新手應該能在沒有協助的情況下完成一整輪驗證並做出報告；每一條規則應該解釋為什麼，而不只是怎麼做；路徑、權限與環境設定應該可被驗證；已知限制應該附上重新檢視的條件；手冊也應該指出失敗、例外與新案例的負責聯絡人。我會在實際交接之前使用這些問題，而不是等前任已經不在了才用。例如，只記下一個緊急聯絡人是不夠的，如果那個聯絡人沒有解決問題的權限；同樣地，只記下一個門檻是不完整的，如果沒有人能解釋它背後的決定。目標是轉移那些讓流程能運作的理由與責任，而不只是讓流程能跑起來的指令。

交接應該保存知識，但不該凍結它

即使一本手冊通過了新手測試，它也不是永久的真理來源。環境會變、責任會移動，曾經合理的規則可能過時。交接還是雙向的：接手流程的人有權挑戰它的假設、質疑沒有解釋的門檻，並提出更好的方法。如果手冊被當成不容置疑的教條，它可能一邊保存過時的做法，一邊勸退修正。因此，一次成功的交接應該提供足夠的上下文，讓下一位 QA 工程師能獨立繼續這份工作，同時留下改進它的空間。我成功轉移了流程的最強訊號，不是新手不加質疑地照著每條指令做，而是他能驗證系統、辨認問題、解釋自己的決定，並在證據不再支持時，有信心地挑戰一條規則。